This page captures the image processing status and notional plan as of July 28 2009. It was written by John Graybeal based on discussions with Brian Schlining, and work to data for BIAUV and Rover.

The automated processing shown at the Image Data Workflow Diagram shows the different pieces of the image processing task. This document addresses three tasks: adding metadata to images; putting images into SSDS; and creating an image index for Brian's software. We'll deal with those in reverse order.

Images index for mosaic tool

For driving the mosaicing of images using the mosaic tool, Brian requested an index in the form of an ASCII text file. John created a draft, with the following headers/content (this content is tab separated):

Time	Center Latitude	Center Longitude	ImageURL	Altitude(m)	Height(m)	Width(m)
20090413T153133.00	38.922086	119.077900	http://ssds.shore.mbari.org/auvbi/missionlogs/2009/2009092/All%20images/DSC_3717.jpg	1.212	1.001	0.997
20090413T153135.59	39.036678	118.963317	http://ssds.shore.mbari.org/auvbi/missionlogs/2009/2009092/All%20images/DSC_3717.jpg	1.212	1.001	0.997

Brian responded with the following requests for changes:

• add Heading (whatever form AUV reports, but make clear which it is)
• add Pitch and Roll (for calculating skew if/when needed)
• make sure the longitude sign is correct (we're negative)
• a precision indication would be very helpful ("either an error estimate or number of significant digits in lat and lon")

Regarding the last point, lat/lon precision is easy because it's fixed in the data set and it's either just the number of digits we provide, or (for meaningful precision) can be calculated from the worst case value of precision in the inputs; whichever is fewer is the one to specify in the header. Error estimate (accuracy) is hard, because it's different at every point (depending on how recent the last GPS or similar fix is) and the distribution has a long tail (worst case error is potentially pretty high). I'm going to suggest starting with precision, but being prepared to add accuracy fields if the data is noisy.

I now suggest the following:

• Time (ISO8601)
• Image Center N Latitude (to n places)
• Image Center W Longitude (to n places)
• Altitude (m)
• Heading (geographic)
• Pitch (deg up)
• Roll (deg right)
• Image URL
• Image Height (m)
• Image Width (m)

Note that calculating Image Height and Image Width will require some mathematics to incorporate the Altitude, Pitch, and Roll of the AUV, as well as the optical characteristics of the system. The camera is a fixed focus camera (or used that way at least), so that makes life easier.

The sequence for performing this post-processing vs the BIAUV Navigation Processing Strategy will eventually be important, as the post-processing has the potential to significantly modify the exact location of each image. However, I propose first using the AUV-calculated navigation information for creating this index, because that should provide a smoothly connected AUV path, which will be the most important characteristic for single-track (non-overlapping) AUV path mosaics.

Putting images into SSDS

As of this writing, images are still being conveyed to shore using a PC or Mac equivalent to mount the images volume on the BIAUV. There is ongoing discussion of making the volume mountable in the native OS, allowing direct copy. In this case it will be a trivial matter to put the images on a store (assuming space is available), and then indexing them in SSDS.

Kevin and I have discussed how best to do this. It is probably not ideal to put an entry for each of 1600 images in a single AUV mission in SSDS. (For example, it would make the navigation of data in SSDS even more difficult.) The best idea I can recall from the discussion is an image index document, that is listed as a resource associated with the source camera sensor.

Note that although it is possible to add images to the SSDS database, we are not doing so because (a) we have not found an optimal submission strategy for such large files, (b) it occupies a lot of space in the database, and (c) we don't have good ways to display image data formats in the SSDS interfaces.

Other considerations

It makes sense to do the images for the AUV in the same way they are managed for the Benthic Rover. This implementation is the most general-purpose, and would be an acceptable starting point for the Rover. Shortly thereafter the Rover may wish to catalog every image in SSDS, as they are not taking as many images and have multiple deployments under which the images are taken.

There is some consideration for putting images into either VARS or the Expd-style systems. This can be accomplished readily if the images have been indexed using SSDS, so SSDS submission will be the first step in any case.

Adding metadata to images

The best mechanism for adding metadata to images in most common formats is ExifTool, which is free software that can be run from a Unix command line. It has an immense range of metadata-setting options and Mike and Kent have both used it. And it can be easily incorporated in any scripting language (or programming language).

The more tricky question is deciding what metadata to add. There are 3 possible additions: corrected timestamps, navigation data, and expanded metadata of the style Mike McCann adds to ROV data.

An important reason to add this metadata to images is to make the images self-describing. Often images from the BIAUV will be separated from their original storage environment (in presentations, on the web, sent to colleagues, and so on). As is generally the case, including metadata inside each image will be important. It allows the image to be traced back to its source (institution, platform, and observation date), and all metadata is easily discoverable with most image software (rather than chasing down the image manually in a data system and using that data system to look up the metadata).

Corrected image timestamps

The existing images are expected to contain timestamps to centiseconds, in both the GPS and 'image timestamp' parts of the metadata. There was some uncertainty (last I heard) about whether this mechanism was working correctly. If it is not, the project has expressed the opinion that they can derive the correct timestamp from other logs. Whichever path is chosen, this should be a priority, as otherwise timestamp information may be hard to recover.

Navigation data

Although a process will create a text document that describes each image (see above) and its navigation/attitude information (see BIAUV Navigation Processing Strategy), it will also be valuable to include that same information in the image itself. This should be a minor modification to the image processing software, and can be made a part of the expanded metadata described in the next section.

ROV (CenSeam) expanded metadata

This metadata will include contact information, copyright and rights of reuse, and so on. It can also include annotation information if annotations are created for the images. Software to add expanded metadata is already operating for the ROVs, and should be easily adoptable for this purpose. The specification for this metadata entry is provided at http://marinemetadata.org/community/teams/imagemd-censeam.